• Desarrollado por el Instituto de Ingeniería del Software (SEI).
• Evalúa las empresas según su grado de capacidad y madurez del proceso. (especie de certificación)
• El SEI sostiene que para lograr ciertos grados de capacidad y madurez hay que ajustarse a las directrices establecidas por la IMCM
• Permite certificar empresas, en base a esa certificación puede suponer que la empresa hace las cosas de esa manera => GARANTÍA DE CALIDAD.

*Puede ser correcto para una cultura organizacional y no para otra.

Es un logro significativo para la ingeniería del software. Proporciona una exposición integral de las actividades y acciones que deben estar presentes cuando una organización construye un software. Aun si una organización no elige adoptarlo, el equipo debería retomar su espíritu y aprender.

¿Por qué necesito la certificación CMMI?

Para demostrarle a terceros que lo que yo hago está bien. Un software certificado implica que tiene un nivel de respaldo.

Es un tercero que opina de que mi empresa cumple con una serie de procedimientos y métodos que aseguran un software de calidad.

Historia: El Departamento de Defensa de los Estados Unidos, no tenía forma de conocer la calidad de las empresas proveedoras de software. Entonces le encargaron a una universidad que elabore una normativa que permita poder evaluar a las empresas que se presentaban a licitación.

Esto luego se convirtió en el modelo CMM.

Características:

• Con CMM todas las empresas están dentro.
• Evalúa la madurez de la empresa en cuanto al desarrollo del software.
• Arranca en el nivel 0 y a medida que mis procesos son cada vez mejores sube el nivel.
• Son más o menos 300 prácticas a llevar a cabo.
• El escalón que denota un salto es el nivel 3.
• El nivel 5 es prácticamente imposible de tenerlo.
• La ley de promoción del software provee a las empresas que tengan como mínimo un nivel 3 en CMM una serie de beneficios a la exportación, subsidios, baja de impuestos, etc.

Niveles:

1. Nivel inicial: acá se ubican todos en un comienzo. No hay métodos ni procesos definidos. Las cosas se hacen de cualquier manera. El éxito o fracaso dependen del programador.
2. Algunos procesos se formalizan. Se ve un poco más de modelos y la diferencia con el primer nivel es que hay alguien que se ocupa de la gestión del proyecto. Aparece el líder de gestión del software.
3. Aplicación de los modelos. Todo está documentado en un marco integrado. Las empresas usan mecanismos para crear software de calidad.
4. La empresa suma métricas y una administración estricta con seguimiento estadístico de lo que pasa. Se ven los desvíos, como te está yendo.
5. Es como el nivel 4, pero además de las estadísticas se crea un marco de mejora continua. Tratar cada vez de hacer mejor las cosas.

Un patrón de proceso ofrece una plantilla: un método consistente para describir una característica importante del proceso de software. Se pueden definir en cualquier grado de abstracción.

1. El método de evaluación de la IMCM estándar para el mejoramiento del proceso (MEIEMP)
2. La apreciación basada en el CMM para el mejoramiento del proceso interno (ABC MPI)
3. El estándar SPICE (ISO / IEC 15504)
4. El ISO 9001: 2000 para software

• Resalta la medida personal del producto de trabajo que se produce y la calidad resultante del producto de trabajo.

Define 5 actividades del marco de trabajo:

1. Planeación: Selecciona requisitos y desarrolla el tamaño y la estimación de los recursos.
2. Diseño de Alto Nivel: Se elaboran las especificaciones externas para que cada componente sea construido y se crea un diseño del componente.
3. Revisión del Diseño de Alto Nivel: Los métodos formales de verificación se aplican a errores descubiertos en el diseño.
4. Desarrollo: El diseño al nivel de componente se refina y revisa.
5. Análisis de Resultados: Mediante las mediciones y medidas recolectadas se determina la efectividad del proceso.

Meta: Construir un equipo de proyecto “autodirigido” que se organice para producir un software de alta calidad.

El PSE define las siguientes actividades del marco de trabajo:

• Lanzamiento
• Diseño de alto nivel
• Implementación
• Integración y Prueba
• Análisis de Resultados

Los escritos del PSE definen elementos del proceso del equipo y actividades que ocurren dentro del proceso.

Actividad Inicial del Proceso: “El Lanzamiento del Proyecto” (cada proyecto es lanzado con una secuencia de tareas que permite al equipo establecer una base sólida para iniciar el proyecto.)

Producto y Proceso

La dualidad del producto y el proceso es un elemento importante para mantener a la gente creativa comprometida mientras finaliza la transición desde la programación hasta la reingeniería del software.

Ingeniería de Sistemas

Se centra en una variedad de elementos mientras analiza, diseña y organiza aquellos elementos de un sistema que pueden ser un producto, un servicio ó una tecnología para la transformación ó control de la información.

La Ingeniería de Procesos de Negocios se aplica cuando el contexto de trabajo se enfoca en una empresa. Cuando se va a construir un producto, al proceso se lo denomina Ingeniería de Producto.

Característica complicada de los Sistemas basados en Computadora: Es que constituyen un macroelemento de un sistema aún mayor. El macroelemento es un sistema basado en computadora que es parte de un sistema mayor basado también en computadora.

El papel del ingeniero de Sistemas es definir los elementos de un sistema específico basado en computadora en el contexto de la jerarquía global de sistemas (macroelementos).

La Jerarquía de la Ingeniería de Sistemas

El proceso de la Ingeniería de Sistemas comienza con una “visión global”, es decir se examina el dominio entero del negocio o producto para asegurarse de que se puede establecer el contexto tecnológico ó de negocios apropiado. Se refina para enfocarse totalmente en un dominio específico de interés.

En la parte alta de la jerarquía se establece un contexto muy amplio, y en la parte más baja se conducen actividades técnicas detalladas, realizadas por la disciplina de ingeniería correspondiente.

La visión global muestra una clara definición de la funcionalidad general que le permitirá al ingeniero entender el dominio y el sistema o producto en el contexto apropiado.

Con el modelo de la ingeniería de Sistemas se logra:

1. Definir los procesos que satisfacen las necesidades de la visión que se considera
2. Representar el comportamiento de los procesos y los supuestos en los que se basa el comportamiento.
3. Definir las entradas exógenas y endógenas de información al modelo.
4. Representar todas las uniones que permiten al ingeniero entender mejor la visión.

Al construir un modelo del sistema se deben considerar algunas restricciones:

1. Supuestos que reducen el número de permutaciones y variaciones posibles, lo que permite al modelo reflejar el problema de una forma razonable.
2. Simplificaciones que permiten la creación del modelo a tiempo.
3. Limitaciones que ayudan a delimitar el sistema.
4. Restricciones que guían la manera de crear el modelo y tomar el enfoque al implementarlo.
5. Preferencias que indican la arquitectura preferida para todos los datos, funciones y tecnología.

Ingeniería de Procesos de Negocios: Una Visión General

Objetivo: Definir arquitecturas que permitan que un negocio utilice información de manera efectiva.

Es un enfoque que crea un plan general para implementar la arquitectura de cómputo.

Arquitecturas que se definen y desarrollan como parte del IPN:

• Arquitectura de Datos: Proporciona un marco de trabajo para las necesidades de información de un negocio o de una función de negocios.
• Arquitectura de Aplicaciones: Abarca aquellos elementos de un sistema que transforman objetos de la arquitectura de datos por algún propósito del negocio.
• Infraestructura de la Tecnología: Proporciona el fundamento para las estructuras de datos y de aplicación. Comprende el hardware y el software con que se apoyan las aplicaciones y los datos.

Ingeniería de Producto: Una Visión General

Objetivo: Traducir el deseo del cliente, de una serie de capacidades definidas, a un producto del trabajo. Para ello se crea una arquitectura y una estructura.

La arquitectura abarca 4 componentes de sistema diferentes:

• Software
• Hardware
• Bases de datos
• Personas

La visión global se consigue mediante la Ingeniería de Requisitos.

Modelado del Sistema

Debido a que un sistema puede representarse con diferentes grados de abstracción (visión global, visión de dominio, visión de elemento), los modelos de sistema tienden a ser jerárquicos estratificados por naturaleza.

• En la parte más alta de la jerarquía se presenta un modelo del sistema completo (visión global)
• A medida que la jerarquía se refina ó estratifica se modela el detalle al nivel de los componentes.
• Al final, los modelos de sistemas evolucionan a modelos de ingeniería que son específicos para la disciplina de ingeniería apropiada.

Modelado de Análisis

Análisis de Requisitos: Genera la especificación de características operacionales de software; indica la interfaz del software con otros elementos del sistema, y establece las restricciones que debe tener el software.

Le proporciona al diseñador de software una representación de información, función y comportamiento que puede trasladar a diseños arquitectónicos, de interfaz y en el nivel de componentes.

El modelo de análisis y la especificación de requisitos ofrecen al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software. (se centra primero en el qué, no en el cómo).

Cumple 3 objetivos primarios:

1. Describir lo que requiere el cliente.
2. Establecer una base para la creación de un diseño de software
3. Definir un conjunto de requisitos que puedan validarse una vez construido el software.

Reglas Prácticas de Análisis

• El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de negocio. El grado de abstracción debe ser alto de forma relativa.
• Cada elemento del modelo de análisis debe agregarse a un acuerdo general de los requisitos de software y proporcionar una visión interna del dominio de información, función y comportamiento del sistema.
• Debe retrasarse la consideración de la infraestructura y otros modelos no funcionales hasta el diseño.
• Se debe minimizar el acoplamiento de todo el sistema.
• Se debe tener la seguridad de que el modelo de análisis proporciona valor a todos los interesados.
• El modelo debe mantenerse tan simple como sea posible.

Análisis de Dominio: El objetivo es crear aquellas clases de análisis ó funciones y características comunes que se aplican ampliamente para que puedan reutilizarse.